The invention is directed to a method for regulating access of computers to data of a central computer.
An excellent field for the application of computer systems in the storing and management of data. Sometimes data can be of an exclusively private nature and there is no interest of distributing or offering such data in the computer system to a plurality of users. A far greater quantity of data, however, should in fact be accessible or distributed: for example, data of a business area, project data or data of a work group.
The crucial questions with respect to the access to distributed data are:
1. How is it assured that the data are always in a validated condition (problem of multiple database organization)?
2. How are conflicts resolved given competing access to the same dataset?
There are various proposed solutions in order to assure consistency of data dependent on the field of application and the demands.
In the publication, ORACLE: Oracle Mobile Agents. Client/Agent/Server Computing, Munich 1996, pp. 5-6, there is disclosed an asynchronous data distribution method. Two computers, R1 and R2, have a limited number of commands available to them that are sent as messages Msg from a client CL on the computers R1 and R2 to an agent AG on a central computer ZR. This is illustrated in FIG. 1 herein. Since all messages Msg can usually not be immediately processed, both the client CL as well as the agent AG have waiting lists available to them. The commands sent in the form of messages Msg trigger pre-defined operations in the agent AG that the agent AG then carries out on shared data GD, for example via SQL (Structured Query Language). In this proposal, client CL and a data server, here, the central computer ZR, with the shared data GD are decoupled from one another.
What is disadvantageous about this asynchronous method are the limited flexibility that is established by the permanently prescribed operations on the data server, the use of the respective computer R1/R2 only as input/output interface without utilizing the calculating capacity on the computers R1/R2, and the availability of the central computer ZR given access of a plurality of computers R1/R2 to the shared data GD or given access via physically poor or, respectively, faulty communication lines. This asynchronous method is also referred to as a "pessimistic" method since the accesses of a plurality of computers R1/R2 to a set of shared data GD would lead to collisions without the asynchronous processing.
In the publication, ORACLE: Oracle 7--Symmetrische Replikation, Asynchron Verteilte Technologie, Munich 1995, pp. 1-12, there is further disclosed that the data access of a plurality of computers R1/R2 to shared data can be synchronously regulated in an "optimistic" method. This is illustrated in FIG. 2 herein. Partial data TD1/TD2 of the shared data GD are replicated on each computer R1 and/or R2, the partial data TD1 on the computer R1 and the partial data TD2 on the computer R2 in this example. Entirely or partly the same datasets can thereby be processed both on the computer R1 as well as on the computer R2. In the example indicated in FIG. 2, access to the individual datasets is regulated via a data bank interface DB-IFC.
In contrast to the asynchronous model described in FIG. 1, there is the possibility of working with a set of commands predetermined by the data bank interface DB-IFC on each computer R1/R2 without connecting to the central computer ZR. This is referred to as a "disconnected mode". The full flexibility of the data bank access is assured in this approach since the datasets are locally present and the data bank interface (for example, an SQL interface) is available for prescribable data ban operations. What is disadvantageous about the synchronous method of FIG. 2 in comparison to the asynchronous method described in FIG. 1 is the lack of assurance of consistent datasets. Instead, however, the availability of the data is correspondingly high since partial data can be maintained replicated on each computer R1/R2 and, thus, each computer R1/R2 has all possibilities of implementing operations on the locally present data that are prescribable by the data bank interface DB-IFC.